Portable battery-driven terminal devices used by transport operators and the like are used continuously for several ten hours in many cases, and how to keep power consumption low has been an important object. As a conventional method for reducing power consumption, sleep control and doze control are used in general (See Patent Literature 1, for example).
In the doze control, a main CPU is brought into a doze state (a state of “shallow sleep” assuming resumption of interruption) and after a predetermined scheduled time of recovery has elapsed or an interrupt event from the outside occurs even before the scheduled time of recovery has elapsed, the CPU is recovered to a normal power operation. The interrupt event while the main CPU is in the doze state is detected by a sub CPU.
However, only with such doze control, power consumption is still large, and achievable continuous use can be only for about ten hours, though depending on a battery capacity. Particularly, with a touch panel terminal device, power consumption for presentation on a large-sized display and power consumption for backlight light source for the display are large, and reduction of power consumption only by the doze control is insufficient.
On the other hand, in the sleep control, a CPU clock is stopped, and the main CPU is brought into a sleep state (a state of “deep sleep” close to power off). In this sleep control, since all the processing (all the processing including internal I/O) of the main CPU is stopped, power consumption can be largely reduced, but if the main CPU is in the sleep state, the CPU clock is also stopped, and a timer in the main CPU goes inconsistent. Therefore, even if the terminal device is provided with schedulers by processing unit such as a task scheduler and a thread scheduler (hereinafter referred merely as a scheduler), the scheduler cannot be used correctly, and an application using the scheduler (application depending on the timer) cannot be implemented, either.
For example, supposing that predetermined task processing is scheduled to be executed 500 milliseconds later by the schedule function of the terminal device, if the main CPU enters the sleep state, the CPU clock is stopped for 400 milliseconds, for example, while in the sleep state, and the main CPU executes the task processing 500 milliseconds after the recovery from the sleep state. As described above, the task should have been executed 100 milliseconds after the recovery from the sleep state of the main CPU, but the timer in the main CPU goes inconsistent due to the sleep control, and the scheduler cannot be used correctly.